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(54)Titte: THIRD PARTY PRIVACY SYSTEM 
(57) Abstract 

A system and method of providing privacy through 
anonymity is described. As one aspect of the invention, a person 
registers at a privacy server (100) and is given a pscudo identity 
that can be used to browse, register, piuchase. pay for, and take 
delivery of products and services. TVansactions are completed 
with the privacy server (ICX)) on a necd-4o-know basis. A seller 
(1 10) conununicates widi the privacy server (1(X)) but only sees 
a demand, not the identity of the buyer (120). The financial 
institution (140) communicates with the privacy server (1(X)) and 
sees die payment, not die merchandise. The freight company 
(150) conmiunicatcs with die privacy server (100) and sees die 
package, not its contents. The privacy server (100) operates in 
a marmer that assures privacy and anonymity for the buyer and, 
if necessary, both the seller as well. 
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THIRD PARTY PRIVACY SYSTEM 

Cross References to Related ApplicationR 

This application relates to the following group of applications. Each application 
in the group relates to, and incorporates by reference, each other apphcation in the 
group. The invention of each apphcation is assigned to the assignee of this invention. 
The group of appUcations includes the following. 
5 "InteUigent Agents for Electronic Commerce", apphcation number 08/784,829, 

ffled January 17, 1997, having inventor Douglas L. Peckover, and claimingpriority from, 
"Intelligent Agents for Electronic Commerce", apphcation nvraiber 60/010,087, filed 
January 17, 1996, having inventor Douglas L. Peckover. 

"Third Party Privacy Systems", apphcation number 60/050,411, filed June 20, 
10 1997, having uiventors Douglas L. Peckover and Jeffrey M. Zucker. 

"Agent Technology for Newsgroups", apphcation number 60/047,341, filed May 
21, 1997, having inventors Carolyn Barthelenghi and Douglas L. Peckover. 

"Ad Agent Method and Apparatus", apphcation number 60/052,373, filed July 11, 
1997, having inventors Carolyn Barthelenghi and Douglas L. Peckover, 
15 "Analysis and Communication Tools for a System", apphcation nxmiber 

60/057,685, filed August 27, 1997, havuig inventor Douglas L. Peckover, 

"Integrated Search and Communications System", apphcation number 
08/970,470, filed November 14, 1997, havmg mventors Jack Axaopoulous, James F. 
Carpenter and Douglas L. Peckover. 
20 Copvright Notice 

A portion of the disclosure of this patent document contains material which is 
subject to copyright protection. The copyright owner has no objection to the facshnile 
reproduction by any one of the patent disclosure, as it appears in the Patent and 
Trademark Office patent files or records, but otherwise reserves all copyright rights 
25 whatsoever. 

The Field of the Invention 
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This invention relates to the filed of electronic privacy. In particular, the 
invention relates to privacy in commercial transaction where electronic communications 
systems are used. 
Background of the Invention 
5 As electronic cormnerce grows in importance, the possibility of maintaining one*s 

privacy becomes more difficult. It has been asserted that the value of a network 
increases proportionally to the number of nodes in the network squared. It has also been 
asserted that the likelihood of maintaining one's privacy decreases as the square of the 
nimiber of nodes in the network. 

10 As consumers make more and more purchases, suppUers and others can build up 

large databases of information about consumers' purchase preferences. The privacy of 
the consumer is lost. 

There is presently no system that allows a user to simply initiate a purchase of a 
physical good without exposing identifying information about the user. Many types of 

15 computer co mmuni cations can be performed using anonymous techniques. However, 
no system presently allows consumers to make purchases anonjnnoxxsly. 

Therefore, what is desired is an improved privacy system that allows consumers 
to make anonjrmous pinrchases. 
A SiimTTi arv of the Invention 

20 A system and method of providing privacy through anonymity is described. As 

one aspect of the invention, a person registers at a privacy server and is given a pseudo 
identity that can be used to browse, register, ptirchase, pay for, and take deliveiy of 
products and services. Transactions are completed with the privacy server on a need-to- 
know basis. A seller commmiicates with the privacy server but only sees a demand, not 

25 the identity of the buyer. The financial institution communicates with the privacy 
server and sees the payment, not the merchandise. The fi:eight company commimicates 
with the privacy server and sees the package, not its contents. The privacy server 
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operates in a manner that assures privacy and anonymity for the buyer and, if necessary , 
the seller as well. 

In some embodiments, the invention includes only the privacy server. Other 
embodiments include the communications system supporting the privacy server. Other 
embodiments include only the software (that is used by the server and/or the consumer 
and/or the seller and/or the financial institute and/or the fireight company) on media or 
in an electromagnetic waveform. 

The system is for all of commerce, and may be used in electronic commerce or by 
people who prefer more conventional commerce, such as a phone call or in-store visit. 

Privacy through anonymity produces more accurate information for sellers, 
enabUng new business tools that permit buyers' needs to be fulfilled more accurately. 

The system has special provisions for protecting the privacy and anonymity of 
children. Parents are given direct control and supervision over their child's 
relationships, as well as where the child is permitted to visit on the Internet. 

Althotigh many details have been included in the description and the figures, the 
invention is defined by the scope of the claims. Only limitations found in those claims 
apply to the invention. 
A Brief Description of the Drawing s 

The figures illustrate the invention by way of example, and not limitation. life 
references indicate similar elements. 

Figure 1 illustrates a third party privacy system. 

Figure 2 throu^ Figure 11 illustrate data structures that can be used in the 
system of Figure 1. 

Figure 12 throu^ Figure 15 illustrate example screen output fi-om various 
locations in the system of Figure 1. 
The Description 
Definitions 
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The following terminology will be helpful m understanding various embodiments 
of the invention, 

A product can be either a good or a service. 

A consumer, or buyer, is any person or company that purchases products, or 
5 would otherwise be interested in receiving information about a product. 

A supplier, or seller, is any person or company that suppUes products, or would 
otherwise be interested in receiving consumer needs' information about a product. 

A financial institution is anyone who would provide credit. In the examples 
described herein, the same financial institution is used in the description. It is 
1 0 unportant to note that multiple different fmancial institutions would normally use the 
system. 

A fi:«ight company is anyone who would ship goods. 

A \iser is a person or company that accesses the system. The user can be a 
consumer, buyer, supplier, or seller. 

15 Figure Descriptions Details 

The following illustrates one embodiment of the third party privacy system. 
Figure 1 includes a third party privacy server 100, seller 110, buyer 120, the Internet 
130, financial institution 140, freight company 150, parent 160, and child 170. The third 
party privacy server 100 includes a collection of sellers 102, a collection of buyers 103, 

20 a collection of financial institutions 104, a collection of freight companies 105, a 
coUection of transactions 106, a coUection of messages 107, a coUection of system ratings 
108, and a collection of parent ratings 109. SeUer 110 includes a seller cUent 112, which 
mcludes a browser appUcation 1 14 and point-of-sale terminal 1 16. Seller cUent 1 12 also 
includes seller server 118 which includes sales history fUe 119. Buyer 120 includes buyer 

25 cUent 122 which includes browser application 124. Financial institution 140 includes 
financial institution server 142, which includes a collection of payment details 144. 
Freight company 150 includes freight company server 152. Parent 160 includes parent 
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client 162 which includes browser application 164. Child 170 includes child client 172 
which includes browser application 174. 

Figure 2 includes seller detail 200 which includes seller ID 201, 
password/password hint 202, seller name/seller address 203, contact information 204, 
5 methods of payment accepted 205 , payment method for service 206, pseudo identity 207, 
and token balance 208. 

Figure 3 includes buyer detail 300 which includes buyer ID 301, 
password/password hint 302, actual name/actual address 303, contact information 304, 
preferences 305, pseudo identity 306, token balance 307, and parent link/child 
10 link/ratings 308. 

Figure 4 includes financial institution detail 400 which includes financial 
institution ID 402, password/password hint 404, name/address 406, contact information 
408, and methods of payment accepted 409. 

Figure 5 includes fireight detail 500 which includes freight company ID 502, 
1 5 password/password hint 504, name/address 506, contact information 508, and methods 
of shipment accepted 509. 

Figure 6 includes transaction detail 600 which includes transaction date/time 602, 
item description 604, and reference/comments 606. 

Figure 7 includes message detail 700, sender ID 701, recipient ID 702, date/time 
20 703, and message 704. 

Figure 8 includes system ratings details 800 which includes ID 802, Web site URL 
804, ratings 806, comments 808, and creating comments 809. 

Figure 9 includes parent ratings detail 900 which includes ID 902, Web site URL 
904, ratings 906, comments 908, and creating comments 909. 
25 Figure 10 includes buyer ID 1000 which includes buyer code 1010, space fill 1020, 

collision code 1030, and check value 1040. 
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Figure 11 includes payment detail 1100, which includes actual identity 1110, 
pseudo identity 1120, a collection of actual payment types 1130, a collection of payment 
rules 1140 and a collection of pseudo payment types 1150. 
Figures 12, 13, 14, and 15 illustrate sample screens. 

5 Re gistration Generally 

The following describes the various registration techniques used in some 
embodiments of the invention. Each of the users of the privacy system needs to register 
with the privacy server. 
Financial Institution Registration 

10 A person from financial institution 140 manually contacts a person at the third 

party privacy server 100 location to register. The person at the third party privacy 
server 100 location registers the financial mstitution 140 by entering identification 
information, including financial institution ID 402, password/password hint 404, 
name/address 406, contact information 408 (phone number, fax number, Internet 

1 5 address, email address). Methods of payment accepted 409 by the financial institution 
server 142 are also entered, including credit card types, debit card types, smart cards 
types, etc. Financial institution details 400 is stored in a collection of financial 
institutions 104 in the third party privacy server 100 and confirmation is sent back to 
the financial information server 142. 

20 In another preferred embodiment, financial institution 140 could use a browser 

application (and secure communication e.g., SSL) to commtmicate with the third party 
privacy server 100 via the Internet 130 to register. 

The financial institution 140 registration process ends when a transaction detail 
600 is added to a collection of transactions 106 indicating the new financi^il institution 

25 140 has been added to a collection of financial institutions 104. Each time there is an 
addition, modification or deletion of information in the third party privacy server 100, 
a transaction detail 600 is added to a collection of transactions 106. 
Freight Companv Registration 
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Similarly, a person firom the freight company 150 manually contacts a person at 
the third party privacy server 100 location to register. The person at the third party 
privacy server 100 location registers the freight company by entering identification 
information, including freight company ID 502, password/password hint 504, 
name/address 506, contact information 508 (phone niunber, fax number, Intemet 
address, email address). Methods of shipment accepted 509 by the freight company 
server 152 are also entered, including the information reqxiired for the third party 
privacy server 100 to be a "power shipper" for the freight company 150. Freight detail 
500 is stored in a collection of freight companies 105 in the third party privacy server 
100 and confirmation is sent back to the freight company server 152. 

In another preferred embodiment, freight company 150 could use a browser 
apphcation to communicate with the third party privacy server 100 via the Intemet 130 
to register. 

The freight company registration process ends when a transaction detail 600 is 
added to a collection of transactions 106 indicating the new freight company 150 has 
been added to a collection of freight companies 105. Each time there is an addition, 
modification or deletion of information in the third party privacy server 100, a 
transaction detail 600 is added to a collection of transactions 106. 
Seller Registration 

As shown in Figure 1, browser apphcation 114 is used by the seller cUent 112 to 
access the Intemet 130 in order to gain access to a collection of sellers 102 on the third 
party privacy server 100. In another preferred embodiment, seller cUent 112 could use 
an in-store point-of-sale terminal 116 to access a collection of sellers 102. in yet another 
preferred embodiment, the seller 110 could use a phone or fax to manually communicate 
with a person at the third party privacy server 100 location, who could then enter the 
information directly into a collection of sellers 102. Seller cUent 112 registers by 
entering identification information, including seller ID 20 1, password/password hint 202, 

-7- 
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seller name/seller address 203, contact information 204 (phone number, fax number, 
Internet address, email address). Methods of payment accepted 205 by seller 110 are 
also entered. In addition, the payment method for service 206 used by seller 110 to pay 
for accessing the third party privacy server 100, as well as for pajring for tokens for 

5 unsolicited messages sent to buyers 120, are entered and could include credit card 
number, credit card name, credit card expiration date, bank accovmt information, and 
letter of credit information. The third party privacy server 100 verifies the payment 
method by sending pa5ncaent details to a financial institution 140 for verification. 
Verification is returned and seller detail 200 is stored in a collection of sellers 102. 

10 Confirmation is then sent back to the seller 110. In another embodiment, the seller 110 
may choose to remain anonymous, in which case, the seller 110 is assigned a pseudo 
identity in a manner similar to Buyer Registration, described below. Registration is 
complete when transaction detail 600 is logged in a collection of transactions 106 
indicating the addition of the new seller 110. 

15 Note that in another embodiment, the seller 110 could have multiple pickup 

addresses stored in seller details 200 that could be matched with the address in the 
pseudo identity 306 of the buyer 1 10. 
Buver Reristration 

As shown in Figure 1, browser appHcation 124 is used by the buyer client 122 to 
20 access the Internet 130 in order to gain access to a collection of buyers 103 on the third 
party privacy server 100. In another preferred embodiment, the buyer 120 could 
manually contact, by phone, fax or regular mail, a person at the third party privacy 
server 100 location and have them manually enter the information into a collection of 
buyers 103. Buyer client 122 registers by entering buyer ED 301, password/password 
25 hint 302, actual name/actual address 303, and contact information 304 (phone number, 
email address, and preferences 305, consideration amomit to be paid by seller cUent 112 
for sending unsoUcited promotions to buyer chent 122, privacy preferences, category 
preferences, and dehvery preferences). 
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Figure 10 shows one embodiment of how the third party privacy server 100 
generates a imique buyer ID 1000. Buyer ID 1000 is generated by taking the buyer ID 
entered by the buyer client 122 and storing it in buyer code 1010, then space-filling space 
fill 1020 so that the total length of buyer ID 1000 is a fixed length, assigning a code to 
5 collision code 1030 to eliminate collision in buyer ID 1000, and generating a check value 
1040, such as a cryptographic hash using DES, of the buyer code 1010, space fill 1020 
and collision code 1030. This unique buyer ID 1000 is then stored in buyer detail 300, 
which is stored in a collection of buyers 103 with the other information entered by the 
buyer cUent 122. 

10 In another preferred embodiment, the third party privacy server 100 could 

generate a series of single-use buyer ID's by incrementing the collision code 1030 in the 
Buyer ID 1000. These imique single-use keys would be given to the buyer 120 in 
advance and would prevent fraudulent use by a third party, particularly when the risk 
of fraudulent use is increased, such as when the buyer 120 commimicates with a seller 

15 110 over the phone or fax, rather than over the Internet 130. Any time a single-use 
buyer ID is used more than once, it woxild indicate a fraudulent use and would permit 
immediate corrective action to be taken by the third party privacy server 100 and/or 
seller 110 and/or financial institution 140. However, it is likely that the third party 
privacy server 100 would identify the error before ans^hing is sent to the financial 

20 institution server 142. 

The third party privacy server 100 passes control to a financial institution server 
142 for payment type registration (not authentication because no pajonent types have 
been entered), with the actual name/actual address 303 entered by buyer client 122. 
Figure 11 illustrates the creation of a payment detail 1100 in a collection of payment 

25 details 144. Actual name/actual address 303 is stored in actual identity 1110. Financial 
institution server 142 next accepts payment details directly fi:om buyer client 122, 
including payment card number, card name and card expiration date for each debit, 
credit, or other type of payment. Other embodiments might include bank checking 
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account nximber or firequent flyer account number. Financial institution server 142 
validates each payment type and stores it in a collection of actual pa3mient types 1130 
for buyer 120. If more than one payment type is entered, rules are also entered to 
determine when a payment type is to be used. In one embodiment, pajnnent type could 
5 be determined by the category of a transaction. For example, travel and other related 
busiaess expenses could be assigned to payment type #1, an American Express credit 
card stored in a collection of actual payment types 1130, while all other categories could 
be assigned to payment type #2, a debit card stored in a collection of actual payment 
types 1130. This will later give the financial institution server 142 more information to 

10 inteUigently serve the buyer's needs in an increasingly automated shopping 
environment. In another embodiment, a pa3anent type could be determined by the 
amotmt of a transaction. In yet another embodiment, it could be determined by using 
one payment type iintil credit is no longer available, then the next type, and so on. 
These rules are stored ia a collection of pa3mient rules 1140. 

15 The financial institution server 142 then assigns a valid but pseudo payment 

identity, comprised of a pseudo ntunber, pseudo name, and pseudo expiration date to 
each of the payment types ia a collection of actual payment types 1130 and stores them 
in a collection of pseudo payment types 1150. The financial institution server 142 then 
creates a pseudo identity for the buyer 120. In one embodiment, this is made up of the 

20 buyer ID, a fictitious street address, actual city, state and zip code. This is stored in 
pseudo identity 1120. Payment details 1100 is then stored in a collection of payment 
details 144 to complete the payment registration. Note that payment details 1100 is 
structured in a way that can rapidly link the pseudo payment type with the actual 
payment types for real-time payment authorization, 

25 Control is then passed back to the third party privacy server 100 with only the 

pseudo identity 1120 and a collection of pseudo payment types 1150, which is stored in 
pseudo identity 306. Buyer detail 300 is then stored in a collection of buyers 103, Note 
that the information from a collection of payment types 1030 and a collection of payment 
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ndes 1040 in payment details 1000 in financial institution 140 are unknown to and 
unwanted by the third party privacy server 100, This limits liabiUty and limits the 
private information required to be stored by the third party privacy server 100. A 
confirmation message sent from the third party privacy server 100 to the buyer cUent 
5 122 is shown in Figvire 12. 

In another embodiment, the third party privacy server 100 could assign a pseudo 
identity 306 for this buyer without having to register a payment type with financial 
institution 140. This would be for people who want a pseudo identity but do not want 
to use it for shopping. 

1 0 Each time there is an addition, modification or deletion of information in the third 

party privacy server 100, a transaction detail 600 is added to a collection of transactions 
106. The buyer registration process is ended when a transaction detail 600 is added to 
a collection of transactions 106 indicating the new buyer has been added to a collection 
of buyers 103. 
15 Eyflmplfi Purchase s arid Rftturns 

The following describes examples of how the privacy system would aUow private 
purchases and returns of physical goods. 
Non e-Ck)mmerce Sale 

Buyer 120 contacts seller 110 by the phone or by an in-store visit. Seller 110 
20 enters the sale information along with the buyer's ID and freight preference (regular, 
express) into a i)oint-of-sale terminal 116 which is connected to the seller server 118. In 
one embodiment, the seller 110 generates a reference number and sale category, and 
sends the seUer ID, buyer ID and sale information via the Internet 130 to the third party 
privacy server 100 for identity authentication. The third party privacy server 100 
25 verifies the seller ID from a collection of sellers 102, and buyer ED from a collection of 
buyers 103, where it also obtains the buyer's pseudo identity 320. 

Next, the third party privacy server 100 determines the preferred payment type 
for the buyer by generating a temporary payment type table from the pseudo payment 
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types in pseudo identity 320, If there is only one pseudo payment type for the buyer, it 
is the only item entered in the table. If the sale category from seller is unknown, the 
first pseudo pasrment type is entered into the table. Otherwise, the most appropriate 
pseudo payment type is considered preferred, based on matching categories. Any 

5 additional pseudo payment types are also added to the table in case the first type is 
refiised (not authenticated). All pseudo payment types are placed in the temporary 
table, with the preferred type at the top. The third party privacy server 100 completes 
the identity authentication by returning the pseudo identity, temporary payment type 
table, and original reference to the seller server 118 and point-of-sale terminal 116. 

10 Since interception of this transaction could permit fraud, the transaction is well 
protected using digital signatures and SSL with both cUent and server side certificates. 

A sale may or may not require pajnnent authentication or deUveiy authentication. 
For example, the buyer 120 mi^t be registering for a free service from the seller 110, 
in which case neither authentication is required. 

15 If the sale does not require a pa5niient, such as for a free sample, then the 

following payment is skipped. The seller server 1 18 next sends the first pseudo payment 
type in the temporary table and the amoxmt of the sale to the financial institution server 
142, for pajrment authentication. This authentication is in the same manner that any 
other payment would be authenticated with any financial institution 140, such as 

20 through the bank authorization network. In one embodiment, the financial institution 
server 142 recognizes the payment type as a pseudo type becaxise of a range check of the 
pa5anent card number, and uses a collection of pseudo payment types 1050, a collection 
of actual payment types 1030 and a collection of pajmient rules 1040 to determine the 
actual payment type to use for the buyer 120. The financial institution server 142 then 

25 completes the pa5anent authentication in the regular manner and generates an 
authorization code which is returned to the seller server 118 and point-of-sale terminal 
116, again in the regular manner. Payment authentication is then complete. If the 
payment authentication is refused, the seller server 118 examines the temporary table 
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to see if other pseudo pajrment types are available. If they are, the process is repeated 
for each pseudo payment type until authentication is successful or xmtil there are no 
more payment types in the table, in which case the buyer 120 is informed of the refusal 
(not being authenticated). 

5 If the sale does not require any merchandise to be deUvered, such as for a service 

item that has been purchased, then the following deUvery authentication is skipped. 
Otherwise, the seller 110 prepares the sale items for pickup using the reference nxmiber 
generated by the point-of-sale terminal 116. Using the freight preference entered on the 
point-of-sale terminal 116, the third party privacy server 100 determines the freight 

10 detail 500 from a collection of freight companies 105 to use, and the address of the 
"power shipper" information and required format from methods of shipment accepted 
509. The third party privacy server 100 then sends the seller 110 a reference number 
for this sale, seller name/seller address 203 from seller details 200 in a collection of 
sellers 102, and actual name/actual address 303 and contact information 304 from buyer 

15 detail 300 in a collection of buyers 103, to freight company server 152 for freight 
authentication. As the "power shipper", the third party privacy server 100 receives 
authentication. If it fails, then the third party privacy server 100 informs the seller 110, 
who informs the buyer 120 and another freight option is authenticated. Note that this 
might require the seller 1 10 voiding or altering the sale because of a possible difference 

20 in the freight charges. Kali freight options fail, then the seller 110 may have to void the 
entire sale. If the freight authentication is successfiil, then the freight tracking number 
is generated by the freight company server 152 and is sent to the third party privacy 
server 100. The freight authentication of the sale is complete. 

The seller 110 completes the sale by verbally giving the seller 110 reference 

25 number to the buyer 120 and storing the sale in the sales history file 119 on the seUer 
server 118. Note that any future relationship between the seller 110 and the buyer 120 
is by the third party privacy server 100. An ongoing, anonymous, private relationship 
is therefore possible after the sale has been completed. 
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Finally, the seller server 118 sends the sale to the third party privacy server 100 
by sending the seller ID, buyer ID, reference number, sale information and sale 
completion code. The sale is completed on the third party privacy server 100 by storing 
the sale in transaction detail 600 in a collection of transactions 106. This includes seller 

5 ID, buyer ID, freight company ID, and other information related to the sale. The seller 
110 or buyer 120 can retrieve information from the transaction detail 600 about this or 
any other sale by using a Seller Inquiry or Buyer Inquiry (described below). Note that 
this can only be done in a way that respects the privacy and anonymity of the buyer 120 
and, in some cases, the seller 110. 

10 If the sale requires a dehvery, the freight company server 152 schedules the 

pickup from the seller 110 in a way that does not identify the buyer 120, but uses the 
reference number generated by the point-of-sale terminal 116. After the package has 
been picked up, the freight company deUvers the package to the actual name and address 
of the buyer 120. Note that this process does not require the freight company to contact 

1 5 the third party privacy server 100 dviring the actual dehvery process, thus making the 
deUvery company's processes self-contained and self-dependent. 

If the sale reqxiires a buyer 120 payment, such as for credit card usage, the issuing 
financial institution 140 sends the buyer 120 on a statement at the end of the billing 
cycle. 

20 Another embodiment could be selecting the pseudo payment type by the amount 

of the transaction. For example, anything over a certain amount could be charged to 
American Elxpress, while anjrthing that is personal and less than $5 could be cyber 
tokens. Everything else coxild be charged to a debit card. 

Another embodiment, the payment authentication of the sale could be processed 

25 by a "black box" computer that is licensed to the financial institution 140. This would 
be a much more secxure and acceptable method of processing than actually chEinging the 
way the financial institution's internal systems operate. 
ftCnnnnprrP Rnlp 
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This type of sale is very similar to the Non-eCommerce Sale described above. The 
differences are noted as follows. The buyer 120 starts the sale by using browser 
application 124 in buyer client 122 to access the Intemet 130 to locate the seller server 
118. Once located, seller server 118 receives the buyer ID, which in the preferred 

5 embodiment, is entered by the buyer 120 for each sale. In other embodiments, the buyer 
ID can be retrieved from the buyer client 122, retrieved from another marketplace 
server, or from an inteUigent agent acting on the buyer's 120 behalf. The seller server 
118 also receives the items to be purchased from the buyer chent 122. The sale is 
processed in the same way as a Non-eCJommerce Sale except decisions that have to be 

10 made, such as for payment and freight options, are entered into the buyer chent 122 
rather than over the phone or from an in-store visit. The sale is completed by the seller 
server 118 by giving the buyer client 122 the sale reference number. The seller 110 or 
buyer 120 can retrieve information from the third party privacy server 100 about this 
or any other sale by using a Seller Inquiry or Buyer Inquiry (described below). 

15 In another embodiment, the seller server 118 could be located and the sale 

processed by an inteUigent agent representing the buyer 120, rather than by direct 
intervention of the buyer 120 using buyer cUent 122. 
Non-ftCoTnTn erce Returns 

Buyer 120 contacts seller 110 by the phone or by an in-store visit. Seller 110 

20 enters the return sale information along with the buyer's ID and, optionally the buyer's 
freight preference, into a point-of-sale terminal 116 which is connected to the seller 
server 118. In the embodiment, the return sale and buyer ID is verified against a sales 
history file 119 stored on the seller server 118 and, if not located, the return request 
could be rejected. Otherwise, the seller server 118 generates a return authorization 

25 munber and sends the seller K), buyer ID and return information via the Intemet 130 
to the third party privacy server 100 for identity authentication. The third party privacy 
server 100 then authenticates the seller ID from a collection of sellers 102, and buyer ID 
from a collection of buyers 103, where it also obtains the buyer's pseudo identity 306. 
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The third party privacy server 100 creates a temporary payment type table in the same 
way as described in Non-eCommerce Sale above. The third party privacy server 100 
completes the identity authentication by returning the pseudo identity, temporary 
payment type table, and original reference to the seller server 118 and point-of-sale 
5 terminal 116. 

If the return does not require a refund, such as for a free sample, then the 
following refund authentication is skipped. The seller server 118 det ermines the refund 
type from the previous payment method from the sales history file 119, or from the 
payment table, as described in Non-eCommerce Sale. This pajnnent type and refund 
10 amount is authenticated by the financial institution as described in Non-eC5ommerce 
Sale. 

If the return does not require any merchandise to be picked up from the buyer 120 
and returned to the seller 110, such as for a service item that is being canceled, the 
following dehvery authentication is skipped. Otherwise, the buyer 120 prepares the 

15 return items for pickup using the return authorization code munber generated by the 
point-of-sale terminal 116. As the "power shipper", the third party privacy server 100 
schedides the pickup in the same way as described in Non-eCommerce Sale above, except 
that the pickup is from the buyer 120 and deUvery is to the seller 110, but still in a way 
that assures the privacy of the buyer 120. Freight authentication of the return is then 

20 complete. 

The seller 110 completes the return by verbally giving the return authorization 
number to the buyer 120 and storing the return in the seller server 118. Again, note 
that any fiiture relationship between the seller 110 and the buyer 120 is by the third 
party privacy server 100. An ongoing, anonymous, private relationship is therefore 
25 possible after the return has been completed. 

Finally, the seller cUent 112 completes the return by sending the seller ID, buyer 
ID, return authorization nximber, return information and return completion code to the 
third party privacy server 100. The return is completed on the third party privacy server 
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100 by storing a transaction detail 600 in a collection of transactions 106. This includes 
seller ID, buyer ID, freight company ID, and other information related to the return. 
The seller 110 or buyer 120 can retrieve information from the third party privacy server 
100 about this or any other return by using a Seller Inquiry or Buyer Inquiry (described 
5 below). 

If the sale requires a buyer 120 refund, such as for credit card usage, the issuing 
financial institution 140 notes this for the buyer 120 on a statement at the end of the 
billing cycle. 

In another preferred embodiment, the seller 1 10 may permit a buyer 120 to return 

1 0 an item without contacting the seller 1 10 first. In this case, the buyer 120 would contact 
the freight company 150 and have it schedxile a pickup from the buyer 120 and have a 
dehvery sent to the seller 110, It would then be up to the seller 110 to enter the return 
into its point-of-sale terminal 116, which would transmit the return to the third party 
privacy server 100 so that the transaction could be stored in transaction detail 600 in 

15 collection of transactions 106. 

f^noTmrtft rce Return ; 

This type of return is very similar to the Non-eCommerce Return described above. 
The differences are noted as follows. The buyer 120 starts the return by using browser 
application 124 in buyer cUent 122 to access the Internet 130 to locate the seller server 

20 118. Once located, seller server 118 receives the buyer ID, which in the preferred 
embodiment, is entered by the buyer 120. In other embodiments, the buyer ID can be 
retrieved from the buyer client 122, retrieved from another marketplace server, or 
obtained by an intelligent agent workmg on behalf of the buyer 120. The seller server 
118 also receives the items to be returned from the buyer cUent 122. The return is 

25 processed in the same way as a Non-eCommerce Sale except decisions that have to be 
made, such as for payment and freight options if any, are entered into the buyer client 
122 rather than over the phone or from an in-store visit. The return can then be 
completed by the seller server 118 by giving the buyer cUent 122 the return 
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authorization nmnber for the return. The seller 110 or buyer 120 can retrieve 
information from the third party privacy server 100 about this or any other return by 
using a Seller Inquiries or Buyer Inquiry (described below). 

In another preferred embodiment, the seller server 118 cotild be located and the 
5 return processed by an intelligent agent representing the buyer 120, rather than by 
direct intervention of the buyer 120 using buyer chent 122. 

Inquiries 

The following describes how inquires wiU be handled. 

10 Bxiver Inauiries 

The buyer 120 uses a browser application 124 to access the Internet 130 to gain 
access to the third party privacy server 100. In another embodiment, the buyer 120 uses 
other means to access the third party privacy server 100, such as phoning an operator 
who has access, or a fax to a person with access or in machine readable fax format that 

15 could access the third party privacy server 100 without an operator. In the preferred 
embodiment, the buyer would provide a buyer ID and password or other identifying 
mechanism to access his or her own buyer detail 300 in a collection of buyers 103, plus 
the corresponding transaction details 600 for buyer 120 in a collection of transactions 
106. 

20 Figure 13 shows the preferred embodiment of the information returned. The 

buyer ID, password, password hint, consideration amoTmt, token balance, privacy, 
category and delivery preferences, actual identity including contact information, and 
pseudo identity including the pseudo payments are all from buyer detail 300 in a 
collection of buyers 103. Note that, in this example, two credit cards were specified by 

25 the buyer 120, but actual card numbers are xmkaown to the third party privacy server 
100. Figure 13 also shows the following information from transaction details 600 in a 
collection of transactions 106: transaction date, transaction time, seller name, 
transaction type, transaction category, transaction amount, freight tracking code, 
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transaction payment type number, transaction reference nvimber assigned by the seller 
110, and transaction comments. The buyer 120 can modify all fields from a collection 
of buyers 103 except for pseudo payment information. For this, control must be passed 
to the financial mstitution 140 in the manner described in Buyer Registration above. 
5 The only field in transaction detail 600 that can be changed is comments 606. 

In another embodiment, the buyer 120 coidd also review other related information 
in a collection of transactions 106, such as which sellers 110 have made Seller Inquiries, 
discussed below, about buyer 120 for the purpose of prospecting for new business. 
Seller TnqiiiriftR 

10 In the preferred embodiment, there are two types of seller inqtiiries. Figure 14 

shows the information from seller detail 200 in a collection of sellers 102, and a 
collection of transactions 106 for a specific seller 110. Figure 15 shows partial 
information firom buyer detail 300 in a collection of buyers 103, and transaction detail 
600 for that buyer ID 301 m a collection of transactions 106 for a specific buyer 120 that 

15 the seller 110 wants to learn more about. 

Figure 14 shows a sample Seller Inquiry. This is started by the seller 110 using 
a browser apphcation 114 to access the Internet 130 to gain access to the third party 
privacy server 100. In another embodiment, the seller 110 uses other means to access 
the third parly privacy server 100, such as a phone call to an operator who has access, 

20 or a fax to a person with access or a fax in machine readable format that could access the 
third party privacy server 100 without an operator. In the preferred embodiment, the 
seller would provide a seller ID and password or other identifying mechanism to access 
the correct seller detail 200 in a collection of sellers 102, and corresponding transaction 
details 600 in a collection of transactions 106. 

25 Figure 14 shows one embodiment of the information returned. The seller ID, 

password, password hint, methods of payment accepted, payment method for service, 
actual name, address, phone, fax, Internet address and email address are all fi^m seller 
detail 200 in a collection of sellers 102. In another embodiment, the seller 110 could also 
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have a pseudo identity if the seller 110 wishes to remain anonymous to buyers 120. 
Figure 14 also shows the following related information from transaction detail 600 in a 
collection of transactions 106: transaction date, transaction time, transaction iype, 
transaction amotmt, and transaction comments. The seller 110 can modify all fields in 
5 seller detail 200 from a collection of sellers 102. The only field in transaction detail 600 
feom a collection of transactions 106 that can be changed is comments 606. 

In another embodiment, other information firom a collection of transactions 106 
could be shown, such as activity for a certain product line, sales for a certain time period, 
or activity for a specific location. In yet another embodiment, the information from a 
10 collection of transactions 106 could be in summary form by combining similar 
transactions. 

Figure 15 shows another sample Seller Inquiry where the seller 110 would 
identify a specific buyer 120 by entering the buyer ID. Figure 15 shows one embodiment 
cf the information returned. The buyer ID, location, consideration amount for 

15 unsolicited promotions, remaining token balance, and category preferences are from 
buyer detail 300. Note that no information is shown that could be used to identify the 
identity of buyer 120. Figure 15 also shows the following related information from 
transaction details 600 from a collection of transactions 106 for buyer ID 301: 
transaction date, transaction time, seller, transaction type, transaction category, 

20 transaction amount, and transaction reference assigned by the seller 110. Note that 
seller and reference number are only shown if this transaction is for the seller 110 
making this inquiry. In this embodiment, the seller 1 10 cannot modify any fields in this 
screen. 

In another embodiment, other information from a collection of transactions 106 
25 could be shown, such as activity for a certain product line, sales for a certain time period, 
or activity for a specific location. In yet another embodiment, the information from a 
collection of transactions 106 could be in summary form by combining CTmilar 
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transactions. In another embodiment, the information from a collection of transactions 
106 could be for a group of buyers 120 who share the same characteristics or behavior. 

In another embodiment, all of the information in seller inquiries could be 
retrieved electronically and sent to the seller server 118 for later processing. 
5 Financial Institution Inquiries 

A financial institution 140 could also make inquiries in a siTnilflr manner as 
described in Seller Inqxiiries above. These mqturies could also be for the routine 
maintenance of financial institution detail 400 by a specific financial institution 140 or 
for inquiries related to one or more buyers 120 from buyer detail 300 and the 

1 0 corresponding transaction details 600. 
Freight Company Inquiries 

A freight company 150 could also make inquiries in a similar manner as described 
in Seller Inquiries above. These inquiries could also be for the routine maintenance of 
freight detail 500 for a specific freight company 150 or for inquiries r^ated to one or 

1 5 more buyers 120 from buyer detail 300 and the corresponding transaction details 600. 
Non-enoTTiTneree nha rge-back 

A buyer 120 may disagree with a charge fix>m a financial institution 140. In the 
preferred embodiment, the following charge-back is described. The buyer 120 uses 
Buyer Inquiry, described above, to locate the transaction in question from a collection 

20 of transactions 106 in the third party privacy server 100. The buyer then contacts the 
financial institution 140 by phone or by accessing the financial institution server 142, 
and identifies himself or herself by providing a buyer ID or actual payment method or 
pseudo payment method. The financial institution server 142 authenticates the buyer 
120 and buyer's claim, and process the charge-back in the regular manner against the 

25 seller 110, but by using the pseudo payment method so that the buyer 120 remains 
anonymous. If the seller 110 wants to get more information about the buyer 120, Buyer 
Inquiries, described above, can be used. If the seller 1 10 wants to communicate with the 
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buyer 120, an Anonymous Message, described below, can be sent from the seller server 
118 to the buyer client 122 via the third party privacy server 100. 
Trackinf f MisBin g Deliveries 

The buyer 120 uses Buyer Inquiries described above to locate the freight tracking 
5 number from a collection of transactions 106 for the missing delivery. As the "power 
shipper", the thfrd party privacy server 100 can then access the freight company server 
162 to obtain the exact status of the delivery, which is then sent back to the buyer 120. 
In another embodiment, the buyer 120 phones a person at the third party privacy server 
100 location and has this person make the inquiry for them. Yet another embodiment 

10 could have the information accessed electronically from the buyer's client 122 and 
returned directly to the buyer's client 122. 

In another embodiment, the seDer 110 could have access to the delivery 
information, but only m a way that assures the anonymity of the buyer 120. This would 
probably require changes to be made on the freight company server to distinguish 

1 5 whether the actual delivery address or the pseudo deUvery address is to be shown to the 
person making the inquiry. 
Anonymous Messages 

A seller 110 can commimicate with a buyer, either as a result of a sale or in an 
effort to make a sale. In one embodiment, the seller 110 uses a browser appUcation 114 

20 in seUer cUent 112 to access the Internet 130 and the third party privacy server 100 to 
locate a specific buyer detail 300 in collection of buyers 103, as described in Seller 
Inquiries above. If the seUer agrees to pay the buyer 120 the consideration amount for 
unsolicited offers and messages, the seller's token balance 208 in seller detail 200 is 
debited and the buyer's token balance 307 in buyer detail 300 is credited, and the 

25 message is sent fix)m seUer server 118 to message detail 700 in a coUection of messages 
107 on the third party privacy server 100. The message is then processed for the buyer 
120 in the preferred manner as described in the above noted related patent applications. 
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The buyer 120 can choose to reply or respond to the message, or can initiate his or her 
own anonymous messages to the seller 110 in a similar manner. 

In another embodiment, the seller 110 may choose to have a message or 
promotion sent to many buyers 120, as described in the application entitled "Analysis 
5 and Communication Tools for a System", application number 60/057,685, filed August 
27, 1997. In yet another embodiment, all commmiication between the seller 110 and 
buyer 120 can be electronic without the use of a browser application 114. 

In another embodiment, the seller 110 might want to remain anonymous, in 
which case the buyer 120 can only respond to the seller 110 through the third party 
10 privacy server 100, in a manner similar to a seller-initiated message described above. 

In the preferred embodiment, when the seller's token balance 208 falls to below 
a predefined amount, the third party privacy server 100 uses payment method for service 
206 to charge the seller 110 for more tokens, which are then credited to token balance 
208 in seUer detail 200. Also note that a buyer 120 can use his or her own token balance 
15 307 as a payment method for a sale, or can redeem these tokens from the third party 
privacy server 100 for cash. 

Note that messages can also be fi:om buyer 120 to buyer 120, which includes any 
combmation of buyer 120, parent 160 or child 170. Also, the structure of a buyer ID can 
be the same as a seller ID and must be imique for both buyers and sellers. 
20 Another ErnhnditTiPTif. - CnmhiTiinp rthe Privacv and Finan cial Servers 

The previous description is for a stand-alone third party server 100. Another 
preferred embodiment would integrate the third party privacy server 100 with the 
financial institution server 142. The seUer 110 would get a sale fix>m the buyer 120, such 
as over the phone or directly firom a browser appUcation 124 as described above. The 
25 buyer 120 would identify themselves with their pseudo payment information. After the 
sale has been received by the seUer server 118, the seller server 118 sends the pseudo 
payment information and sale amount to the financial institution server 142 for identity 
and payment authentication, where it is processed in the same manner as described 
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above. Briefly, financial institution server 142 converts the pseudo payment information 
into actual payment information, authenticates it, and returns it to the seller client 112 
with an encrypted delivery address of the buyer. When the sale is completed, the seller 
dient 112 schedules the delivery by passing the sales reference nimiber and encrypted 
deUvery address to the freight company server 152. The package is picked up by the 
firei^t company 150, the address is d^rypted and the package is delivered to the buyer 
120 without ever revealing the actual name and address of the buyer 120 to the seller 
110. Return requests would be processed in a similar manner, where the financial 
institution 140 authenticates the pseudo payment information and includes an encrypted 
buyer 120 pickup address and normal seller 110 delivery address, again without ever 
revealing the actual name and address of the buyer 120. 
Children's Privacv 

As described above, a buyer 120 can register on the third party privacy server 100 
and be assigned a pseudo identity that permits him or'her to have an anonymous 
relationship with sellers 110. There is nothing to prevent a child from also registering 
and being assigned a pseudo identity in order to protect the privacy of that child. 
Parent/Child Registration 

How a parent or child accesses the third party privacy server 100 is functionally 
identical to the way a buyer accesses the third party privacy server. However, for the 
sake of clarity, the parent 160 uses browser application 164 and parent chent 162 to 
access the Internet 130, and the child 170 uses browser application 174 and child client 
172 to access the Internet 130. Also, for the sake of clarity, the actual key is in brackets. 
The parent 160 registers in the same manner described in Buyer Registration described 
above, with the following exceptions: the parent 160 also enters the child ID (buyer ID 
301) of each child 170, which is stored in parent Unk/child link/ratings 308 for the parent 
record (buyer detaU 300). The parent 160 then registers each chHd 170 in the same 
manner, this time specifying the parent ID (buyer ID m 301) which is stored in parent 
Unk/child link/ratings 308 for the child record (buyer detail 300). The parent also stores 



.24- 

SUBSTITDTE SHEET (RULE 26) 



wo 99/66428 



PCT/US99A37S2 



the ratings, discussed in a Web Rating System below, that the child 170 is permitted to 
access in parent Imk/child link/ratings 308. Note that parent Unk/child link/ratings 308 
is structured is a manner so that the third party privacy server 100 can immediately 
determine if the current buyer detail 300 is for a parent 160 or a child 170, as well as 
determine the corresponding child 170 records for a given parent 160, or parent 160 
record for a given child 170. 

Accessing Web Sites, a Child Remaining Anonvmous 

The parent 160 accesses Web sites, shops, pays for, and takes deUveiy of items, 
returns items, makes inquiries, traces missing packages, etc. in exactly the same way as 
described for buyers 120 above. The child can also access Web sites but caimot purchase 
any items because of the missing payment information in pseudo identity 306. 
Specifically, the child can access Web sites and register for games, free samples, and the 
various other things being offered by seUers 110, by entering their child ID (buyer ID 
301) at the seller server, but not theu: name, address,, or any other identifiable 
mformation. This then permits the child 170 to have an anonymous relationship with 
the seller 110 (or any Web site owner). If the seller 110 requires more information, the 
seller 110 makes a Seller Inqxiiry, described above, and sees a warning on the screen 
explaining that this person is a child. The seller 110, or anyone else, can therefore have 
an anonymous relationship with the child 170 and visa versa by sending Anonymous 
Messages, as described above. 
Parental Supervision of the Child's RelatinnHhip B 

Every time a seller 110 accesses the third party privacy server 100 to inquiry 
about a child 170, or every time there is an Anonymous Message sent to or fi-om the child 
170, the child's parent Unk/child Unk/ratings 308 is used to identify the parent 160 
(buyer ID 301) and the event is logged in transaction detail 600 in a collection of 
transactions 106 for the parent 160. This permits all anonymous behavior of the child 
170 to be monitored by the parent 160. 
Web Ratinpr Svstem 
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A collection of system ratings 108 on the third party privacy server 100 contains 
records described in system ratings detail 800. Each record contains an ID 802 of a 
buyer 110, seller 120, parent 160 or child 170 being rated, a Web site URL 804, a rating 
806 with the ratings for the ID 802 or Web site URL 804 and is shnilar to the TV ratings 
5 system that describes adult content, violence content, suggested age groups, etc., 
comments 808 xxsed to describe the rationale behind the ratings 806 given, and creating 
comments 809 containing the creating date, time and author ID of the system ratings 
detail 800. In each system ratings detail 800, at least one of ID 802 and Web site URL 
804 must be specified. 

10 A parent 160 can maintain his or her own personal parent ratings detail 900 to 

override or add to records in system ratings detail 800. The fields are the same. 

Each time a child 170, as defined in parent link/child link/ratmgs 308, tries to 
send or receive an anonymous message, the third party privacy server 100 accesses 
parent ratings detail 900 to see if the person receiving the message from the child^l70 

1 5 or sending the message to the child 170 has a record in parent ratings detail 900 with the 
same ID 902. If there is no record, system ratings detail 800 is also checked in the same 
manner. If there is no record in either parent ratings detail 900 or ratings system detail 
800, the anonymous message is processed as described in Anonymous Messages above, 
and the event is recorded in transaction detail 600 for the parent 160 referenced in the 

20 parent link/child Imk/ratings 308 for that child 170. 

If there is a match, the rating in the child's parent link/child link/ratings 308 is 
compared to the ratings 906 or 806 to see if this child 170 is permitted access to this ID. 
Kpermission is granted, the message is processed as though no record in parent ratings 
detail 900 or system ratings detail 800 was found. If permission is not granted, then the 

25 message is not processed and the event is recorded in transaction detail 600 for the 
parent 160 referenced in the parent link/child link/ratings 308 for that child 170. 

In a similar manner, each time a child 170 tries to access a Web site, a plug-in in 
the browser application 174 for the child 170 asks permission from the third party 
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privacy server 100, by accessing parent ratings detail 900 and then ^stem rating detail 
800, this tune matching the desired URL with Web site URL 904 or 804 respectively. 
Permission is granted or not granted, and processingcontinues or is stopped, in the same 
manner described for a child 170 sending or receiving messages. 
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What is claimed is: 

1. A server for providing privacy to consumers, the server comprising a program for 
generating a pseudo-identity that can be used to browse, register, purchase, pay for, and 
take deUvery of goods, the pseudo-identity permitting a seller to access a purchase 

5 demand associated with the pseudo-identity, the pseudo-identity permitting a financial 
institution to see payment information, the pseudo-identity permitting a freight 
company to deUver the goods. 

2. The server of claim 1 wherein the pseudo-identity can be used during Internet 
1 0 based browsing. 

3. The server of claun 1 wherein the seller cannot identify the user associated with 
the pseudo-identity. 

1 5 4. The server of claim 1 wherein the financial institute cannot identify the goods. 
5. The server of claim 1 wherein the freight company cannot identify the goods. 

20 
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Here is the pseudo delivery address ond credit cords that you will 
use when placing a private, anonymous order: 

Mr. FREDSTONEOl 23234 
1 Main Street 

[actual city] [actual state] [actual zip code] 

Credit card [pseudo card number] for T&E 

Debit cord [pseudo card number] for everything else 

There is no need to record this becouse on intelligent agent will 
remember oil of it for you. Your actual credit card(s) will be used by 
a certified bonk. Your actual name ond address will only be used by 
certified freight companies. All parties ore audited by Emst & Young 
to ensure thot your privacy is not violated. 

Your registration is now complete - thonk you. 
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